@mmatera I haven't begun to add the needed bug fixes for #1237 but this is already starting to get large.

@mmatera I haven't begun to add the needed bug fixes for #1237 but this is already starting to get large.

My only comment here is that walk_parts got its name from walk_levels, a routine already existing in the old Mathics code. That routine allowed both to find a part of a expression or to apply a function over some of the parts.

@mmatera I haven't begun to add the needed bug fixes for #1237 but this is already starting to get large.

My only comment here is that walk_parts got its name from walk_levels, a routine already existing in the old Mathics code. That routine allowed both to find a part of a expression or to apply a function over some of the parts.

As the code is currently written, eval_Part exactly handles the Part[] built-in function when we don't have a ByteArray. Therefore it is exactly the kind of function that we have been calling eval_ and placing with a similar modular structure as builtin in mathics.eval.

Initially, my thought was that functions called eval_Xyy are likely to be the implementation of some future instruction set which would be used after compilation.

But what I am coming to appreciate in doing the debugger work is that by making things regular in this particular way, it makes things easier on a debugger or some other similar introspection tool. If I want to show, track, or stop at key parts of execution, looking for in routines in mathics_eval that have the name eval_Xyy (as opposed to eval_Xyy and walk_???) may be helpful.

And usually if I go up one level in a call stack often there will be an eval method which is also probably of interest.

Sure, I understand that a lot of what is there now may have some historical precedent. And the name walk_xxx conveys some sort of idea and possibly groups things along some lines.

In contrast to calling "elements", "leaves" or "eval" routines "apply", it is not a bad name or wrong, just not as helpful for the ways in which the code is currently envisioned to be organized in a way that makes it helpful to scale in the future.

It may very well be that in the future we may move and rename "walk_levels". For example that may also be the bulk of some builtin-function evaluation routine as well.